ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
floof58 has quit [Ping timeout: 480 seconds]
Brainium has quit [Remote host closed the connection]
floof58 has joined #wayland
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
kts has joined #wayland
lsd|2 has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
Fischmiep has quit [Quit: ZNC - https://znc.in]
fmuellner has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
Fischmiep has joined #wayland
Company has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
mxz has quit [Quit: cya]
mxz has joined #wayland
kts has quit [Quit: Leaving]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
rv1sr has joined #wayland
sevz has quit [Quit: Client quit]
glennk has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
AJC_Z0 has joined #wayland
AJ_Z0 has quit [Read error: Connection reset by peer]
AJC_Z0 is now known as AJ_Z0
sima has joined #wayland
privacy has joined #wayland
garnacho has joined #wayland
sima has quit [Quit: Leaving]
sima has joined #wayland
lbia has quit [Ping timeout: 480 seconds]
narodnik has quit [Remote host closed the connection]
narodnik has joined #wayland
rgallaispou1 has quit [Remote host closed the connection]
rgallaispou has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
<pq> emersion, what do you think, do you want to make a libdisplay-info release before mid-Jan?
Dami_Lu has joined #wayland
glennk has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
rv1sr has quit []
leon-anavi has joined #wayland
<wlb> wayland-protocols Merge request !103 closed (Draft: alternative present-timing protocol)
<wlb> wayland-protocols Merge request !250 closed (build: move unstable protocols to staging)
mvlad has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
kts has joined #wayland
narodnik2 has joined #wayland
peeterm has quit [Quit: Leaving]
kts has quit [Quit: Leaving]
peeterm has joined #wayland
rasterman has joined #wayland
kts has joined #wayland
lbia has joined #wayland
fmuellner has joined #wayland
qaqland is now known as Guest10453
qaqland has joined #wayland
kts has quit [Quit: Leaving]
narodnik2 has quit [Quit: WeeChat 4.1.2]
narodnik2 has joined #wayland
Guest10453 has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<wlb> weston Merge request !1421 opened by Pekka Paalanen (pq) libweston: drop weston_output_init() test workaround https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1421 [Core compositor]
<Company> so, I've been thinking about this somewhat seriously after the recent dmabuf discussion in #dri-devel
<Company> how much benefit do compositors get from apps using dmabufs vs shmem?
<pq> depends on what kind of dmabuf and what kind of compositor (KMS, GPU or software compositing)
<Company> because I don't see it as too hard to replace the GTK3 wl_shmem code with VkAllocateMemory() + wl_linux_dmabuf
<emersion> please don't
<emersion> rendering directly to a mmap'ed dmabuf will be super slow
<pq> that depends on what kind of dmabuf
<emersion> VkAllocateMemory() is like a dmabuf-dmabuf
<soreau> if it ain't broke.. don't fix it :P
<emersion> the composiutor is in a better place to figure out the best way to get the pixels on the GPU
<emersion> and on which GPU
<pq> FWIW, Weston does not support dmabuf with pixman-renderer, and never attempts to read dmabuf contents into CPU domain. So if it fails import to EGL, it's rejected.
<soreau> Company: do you mean for a vulkan-only path? or something else..?
<Company> I mean literally just as a replacement for the wl_shmem buffer
<Company> that cairo draws to
<Company> so that the compositor can aovid the glTexImage2D() calls
* emersion invokes MrCooper
<soreau> Company: but wouldn't you have to upload the buffer to the gpu somehow anyway?
<pq> Company, well, wl_shm buffers are explicitly optimal for CPU access. Dmabuf usually is not, so it's uncommon to attempt CPU access to dmabuf.
<Company> but I have no idea if that's useful and what to care about when it is
<Company> but it's not too hard code-wise, so if it's beneficial: why not
<pq> Company, why do you think you can import such sw dmabuf into a hardware GPU EGL or VK context? I didn't think that worked in general.
<emersion> pq, it is not a sw dmabuf
<emersion> it is a GPU dmabuf mmapped for CPU rendering
<pq> and if the dmabuf is importable to GPU hardware, then why would it be a good idea to render into it with CPU?
<Company> it's not a good idea - it's just what GTK3 does
<Company> all I want is to back the GTK3 buffer by memory that the GPU can use
<emersion> if you do CPU rendering, just use wl_shm
<Company> like, I'd imagine that on integrated GPUs, that shouldn't be too hard
<pq> well, if you are only looking to move the glTexImage2D equivalent operation into client-side, that's fine. But then it's a copy, not drawing.
<Company> I'm looking to avoid the glTexImage2D() call entirely
<emersion> on integrated CPUs, the GPU memory is still special
<emersion> integrated GPUs*
<Company> but is it so special that it shouldn't be used as a cairo surface's buffer?
<emersion> yes
<Company> why is that?
<pq> while integrated GPU memory is not behind a "slow" bus, it's still usually hostile towards CPU rendering I believe, at least due to the cache mode.
<Company> I'd have thought that it's fine as long as it's HOST_CACHED
<pq> like write-combining vs. writeback vs. uncached
<soreau> Company: would this even work with !vulkan? or the plan would be to fall back in that case?
<Company> soreau: the plan would be to fall back of course
<Company> this would just be a fast path
<soreau> hm
<soreau> make sure to add an env var to force the fallback path :P
<pq> if you pick a good caching mode for CPU rendering, does that not make GPU texturing from it more expensive?
<Company> I'd have assumed something like DEVICE_LOCAL | HOST_CACHED would work
<Company> my AMD doesn't have that, but Intel does
<soreau> Company: but TBF, this sounds like a place for a gtk4 experiment, not gtk3 :P
<Company> gtk4 doesn't render with Cairo
<soreau> well, not always..?
<Company> gtk4 renders with Cairo if eglInitialize() fails
<Company> ie your GPU driver is broken
<Company> Intel has 3 memory types on Vulkan: DEVICE_LOCAL, DEVICE_LOCAL | HOST_VISIBLE, and DEVICE_LOCAL | HOST_CACHED
<soreau> well it wouldn't be too great if this idea caused some sort of bug, with performance or otherwise, that users have to hack around somehow
<Company> and they all use the same 32GB heap, aka my RAM
<Company> but I have no idea what that means
kts has joined #wayland
mango has joined #wayland
<mango> Hi. I’m writing a simple Wayland background daemon just to kind of learn a bit about how writing Wayland clients work and all that. At the moment I’m making use of the viewport protocol to have the compositor scale my images for me and it’s working great, but I would also like fractional scaling. I’m trying to use the fractional scale protocol but I’m utter confused with how it works
<mango> Specifically, the documentation says that if I have a surface of size 100x50, I should submit a buffer of size 150x75 (if scaling with 1.5)
<mango> Does this mean that I need to manually scale the buffer up myself? Doesn’t that defeat the purpose of using viewport?
<Company> you create a 150x75 buffer and set it via viewport to cover the 100x50 window
<Company> but if you're using the viewport for your own scale anyway, then it doesn't matter to you if the output is fractionally scaled or not I guess?
<zamundaaa[m]> mango: if you're having the compositor up- or downscale the image already, then fractional scaling is useless to you
<mango> zamundaaa: At the moment the compositor does scaling for me, but only integer scaling to ceil(<my scale>)
<zamundaaa[m]> mango: no, the compositor scales to the pixels on the screen
<zamundaaa[m]> The logical size you tell it is just an intermediary coordinate space
<wlb> weston Merge request !1422 opened by Pekka Paalanen (pq) Rename compositor/ to frontend/ https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1422 [Testing], [Weston frontend]
<mango> zamundaaa: I see my issue, I’m not supposed to call set_buffer_scale anymore
<mango> I missed that part of the docs
<mango> All works fine now, cheers
<pq> You can set_buffer_scale and make it work with wp_viewport, but it does make things more complicated for you and has no benefit.
mango has quit [Quit: leaving]
garnacho has quit [Quit: garnacho]
kts has quit [Quit: Leaving]
<pq> Actually, isn't it a compositor bug, if viewport destination size is set, and buffer scale affects the destination size? That's how I could understand what mango said.
garnacho has joined #wayland
Moprius has joined #wayland
<emersion> lol re that MR: i was thinking about putting my protocol impls in frontend/
<pq> user frontend vs. protocol frontend?
<wlb> wayland Issue #428 opened by Gg wp (FrolovRuslan1) User help with XKB https://gitlab.freedesktop.org/wayland/wayland/-/issues/428
<pq> or is it the backend that is user facing? hmm...
<emersion> to me the compositor sts between the clients and KMS
<emersion> that KMS-facing part is the backend, th client-facing part is frontend
<emersion> but yeah, just my own view i suppose :P
<pq> but it also includes UI aspects like configuration and CLI, right?
<emersion> these are orthogonal to me
<pq> side-end?
<emersion> yeah :P
<emersion> not sure if i could come up with a better name
<emersion> (feel free to disregard my comments, this was more of a fun fact than anything else really)
<pq> picking names is usually hard
<emersion> just call it "other-end"
<emersion> (j/k)
<pq> "the thing that loads the compositor libs and configures the pieces into a working compositor"
<pq> loader?
<pq> maybe not
<emersion> "core" doesn't sound right either
<emersion> "main" is confusing
<pq> yup, our core is in the compositor libs
<emersion> ("main" to mean that it contains the main function but eh)
<ManMower> scaffolding
<pq> main.c is in there, but so is a lot more
<emersion> "bin"?
<pq> clients/ is separate, and it's full of bins
<emersion> "weston" wouldn't be helpful
rv1sr has joined #wayland
<pq> There is already a Gitlab label "Weston frontend" for things in this dir.
Moprius has quit [Quit: bye]
<wlb> weston Merge request !1423 opened by Pekka Paalanen (pq) backend-drm: store EDID data https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1423 [DRM/KMS backend]
privacy has quit [Quit: Leaving]
sima has quit [Ping timeout: 480 seconds]
kts has joined #wayland
nerdopolis has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
manuel1985 has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
jtbx has quit [Remote host closed the connection]
jtbx has joined #wayland
privacy has joined #wayland
sevz has joined #wayland
glennk has joined #wayland
fullstop has quit [Quit: ZNC - http://znc.in]
fullstop has joined #wayland
nerdopolis has joined #wayland
fullstop has quit []
fullstop has joined #wayland
leon-anavi has quit [Remote host closed the connection]
jkl has quit [Quit: Gone.]
jkl has joined #wayland
kts has quit [Quit: Leaving]
andyrtr has quit [Quit: ZNC 1.8.2 - https://znc.in]
andyrtr has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
nerdopolis has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
Brainium has joined #wayland
dos1 has quit [Quit: Kabum!]
dos1 has joined #wayland
nerdopolis has joined #wayland
Company has quit [Remote host closed the connection]
mohit8158226 has quit [Quit: mohit8158226]
mohit8158226 has joined #wayland
puck__ has joined #wayland
puck_ has quit [Quit: -w-]
puck__ is now known as puck_
puck_ has quit [Remote host closed the connection]
puck_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
rgallaispou1 has joined #wayland
rgallaispou has quit [Ping timeout: 480 seconds]
lsd|2 has joined #wayland
rgallaispou1 has quit [Read error: Connection reset by peer]
mvlad has quit [Remote host closed the connection]
rgallaispou has joined #wayland
narodnik2 has quit [Ping timeout: 480 seconds]
lsd|2 has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
i509vcb has joined #wayland
rv1sr has quit []
glennk has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
GentooPhysicist3935426 has quit [Remote host closed the connection]
bodiccea has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
azerov has quit []
nerdopolis has joined #wayland
azerov has joined #wayland