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
leon-p has quit []
pnowack has quit [Quit: pnowack]
Lucretia has quit []
rasterman has quit [Quit: Gettin' stinky!]
columbar1 has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
columbar1 has quit []
columbarius has joined #wayland
hegstal has quit [Remote host closed the connection]
[[OneLegend]] has joined #wayland
boistordu_old has joined #wayland
boistordu has quit [Ping timeout: 480 seconds]
xexaxo_ has quit [Ping timeout: 480 seconds]
<ishitatsuyuki>
won't run X? that happens?
<ishitatsuyuki>
anyway in Wayland it's up to the compositor to handle global key events (which breaks these use cases that worked in X)
<ishitatsuyuki>
sway might work given there's a lot of config options, idk
<ishitatsuyuki>
for other compositors, I guess you are out of luck
<danieldg>
sway doesn't have a good inject-key command yet
<[[OneLegend]]>
hi danieldg!
boistordu_old has quit [Remote host closed the connection]
boistordu_ex has joined #wayland
<technomancy>
ishitatsuyuki: I can use Xwayland but certain things (in particular love2d) crash on launch
<technomancy>
but that's helpful to know it would need to be sway-specific
<danieldg>
yeah, binding global shortcuts in general is compositor-specific on wayland
radu242 has joined #wayland
zebrag has quit [Remote host closed the connection]
boistordu_ex has quit [Remote host closed the connection]
radu242 has quit [Ping timeout: 480 seconds]
boistordu_ex has joined #wayland
naveenk2 has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
[[OneLegend]] has quit [Quit: WeeChat 2.8]
naveenk2 has quit []
naveenk2 has joined #wayland
pnowack has joined #wayland
<emersion>
the plan for sway is something like `bindsym Ctrl+p keyboard press ArrowUp`
<emersion>
but yeah not done yet
naveenk2 has quit []
remanifest has joined #wayland
remanifest has quit []
danvet has joined #wayland
remanifest has joined #wayland
remanifest has quit []
remanifest has joined #wayland
naveenk2 has joined #wayland
remanifest has quit [Remote host closed the connection]
audgirka has joined #wayland
naveenk21 has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
naveenk21 has quit [Ping timeout: 480 seconds]
naveenk2 has quit [Ping timeout: 480 seconds]
audgirka_ has joined #wayland
audgirka_ has quit []
audgirka_ has joined #wayland
audgirka has quit [Ping timeout: 480 seconds]
Lucretia has joined #wayland
audgirka_ has quit [Ping timeout: 480 seconds]
audgirka has joined #wayland
rasterman has joined #wayland
gryffus has joined #wayland
gryffus has quit [Remote host closed the connection]
gryffus has joined #wayland
AJ_Z0 has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
<pq>
technomancy, those docs you find, are they not about editing and installing a new keymap? I would have thought the same could apply to combos. This doesn't sound like you wanted global shortcuts.
<pq>
hmm, but I wonder if a keymap can translate a keysym-combo into another keysym... it's all so complicated.
<emersion>
daniels: ah, fwiw, i've bitten the bullet and completely replaced wl_drm with my own impl
<emersion>
in wlroots
<daniels>
emersion: you what?
<daniels>
you've got your own server-side implementation of wl_drm?
<emersion>
yes
<pq>
to avoid having to pass EGLImage around in your APIs?
<daniels>
porquoi?
<daniels>
oh
<daniels>
is the answer VA-API?
<emersion>
yes, basically to make wl_drm buffers behave exactly just like linux-dmabuf ones
<daniels>
putain
<emersion>
and avoid any interaction between EGL and wayland protocol things
<pq>
alright :-)
<daniels>
I mean, fair enough, I don't think it'll bite you in any of the non-Mesa stacks who do bind_wayland_display without wl_drm
<emersion>
EGL's ext is especially a paiun to support with our API choices
<emersion>
pain*
<daniels>
(i.e. those aren't the devices you care about)
<daniels>
but what do you have left still using wl_drm? is it just VA-API?
<emersion>
yes, arm or w/e proprietary driver with their own custom wl protocols, i don't care about
<emersion>
wl_drm is used by vulkan's wsi
<emersion>
but i fixed it :)
<emersion>
so at some point our wl_drm impl will basically just be the device advertisment
<emersion>
and will error out if you try to creeate a buffer with it
<daniels>
someone should probably make some kind of extension to zwp_linux_dmabuf that does device advertisement :P
<daniels>
(I guess you saw leandrohrb is also working on hints for VKWSI?)
<emersion>
lol
<emersion>
ah, no, that's very nice!
gryffus has quit []
<daniels>
we're determined to get there! soon!
<emersion>
:D
xexaxo_ has joined #wayland
<naveenk2>
Hi pq: I was going through the list of tasks and in progress tasks from CM&HDR implementation roadmap (#467) · Issues · wayland / weston · GitLab (https://gitlab.freedesktop.org/wayland/weston/-/issues/467). I am still trying to understand the current state of the color pipeline.
<naveenk2>
As far I could figure out, I see a basic framework is in place and current development for CM is being done through gl-renderer (gl-shaders), out of which gamma blending with EOTF and Inverse of EOTF for default sRGB color is implemented with no-op for color transformation (or mostly due to content & target colorspace is default). Please correct my level of understanding on these.
<naveenk2>
what are the pending tasks you see to make sure atleast the basic color pipeline with default colorspace sRGB can be tested.
<pq>
naveenk2, you are correct. The color pipeline as in upstream right now is complete and correct for sRGB input with sRGB output, doing the blending in light-linear space.
<pq>
naveenk2, you can use the weston.ini option to turn color management on, and you will get the light-linear blending, which you can notice affecting all semi-transparent pixels more or less.
<pq>
doing this will also stop most of the KMS hw planes usage, as the color transformations are not implemented in DRM-backend yet.
<pq>
the test suite also has a test to ensure both light-linear and the old non-linear blendign keep working: alpha-blending test.
hegstal has joined #wayland
<naveenk2>
pq: thats great to hear. I will surely give it a try.
<naveenk2>
also do you think, we can start implementing color pipeline using DRM KMS hardware pipe/plane level APIs in parallel to the current gl-renderer/shaders work.
<naveenk2>
and try replicating the same using DRM KMS
damjan has quit [Quit: bye]
damjan has joined #wayland
<pq>
naveenk2, sure. There is one catch with that: there is code smashing the legacy gamma libdrm function, that needs to be migrated away. I just sketched that a bit in the roadmap today.
<naveenk2>
pq: Ok I will work with shankaru offline and get the kernel changes also refreshed (with documented kernel APIs).
<pq>
naveenk2, ah, you're working on the per-plane degamma/ctm/gamma?
flacks has quit [Quit: Quitter]
<pq>
naveenk2, it may be a while until struct weston_color_transform can actually feed a CTM. It will have 3D LUT first, Vitaly is working on that. And we will be on holidays most of August.
flacks has joined #wayland
leon-p has joined #wayland
<naveenk2>
pq: ok I will check the current implementation and try to understand the gaps for feeding CTM in the color pipeline.
<pq>
naveenk2, I think the CTM on color-lcms side may be best left for Vitaly to do.
<pq>
naveenk2, this Weston implementation spree is just a little interlude before getting back to the protocol design work, which is still very much WIP.
<pq>
naveenk2, I explained this in the Weston CM&HDR roadmap: stuff we can do without a protocol, and stuff we will need the protocol for.
<naveenk2>
pq: right I have seen them
<pq>
but we can't finish the protocol work without a long period of practical experimentation, so we need as much implementation in Weston first as possible
<pq>
committing to a protocol before that would be foolish
<naveenk2>
pq: sure I completly agree to that.
<naveenk2>
also what you think about the pre-curve and post curve implementations for per layer linearization in case when multiple clients are active at once submitting layers and converting them to linear space and then blending it together. I believe current implementation is all on the whole pipe level blended data
<pq>
naveenk2, where's your protocol XML? I don't see it.
<pq>
naveenk2, I don't understand what the question there is.
<naveenk2>
What I meant is currently EOTF curve is applied on the blended data, but what about the multi plane use case? where each planes will have different colorspace
<pq>
naveenk2, what do you mean "on the blended data"? No, that would be wrong.
<pq>
EOTF is applied on each surface before blending (during texturing, more like)
<pq>
inverse EOTF is applied after blending, before or during scanout
<naveenk2>
Ok I think that make sense then
<naveenk2>
I was wrong about the EOTF being applied on the blended data. so that should be fine
<naveenk2>
pq: We are planning to try out Weston CM work next week and see if we have any queries which we can check with you before you go for vacation. Hope you are available next week :)
<pq>
Alright. Yes, I'll be here next week, but not much after that. :-)
<naveenk2>
pq: Okay that would be great. see you soon
<daniels>
it's all a little bit opaque, but my reading of what went on is that flush/inval was actually secretly for resolving compression when using a compression-aware external sink
<daniels>
back when AMD didn't do modifiers
<ManMower>
reverted! exciting. :)
<daniels>
I think we could revive that to not necessarily do resolve-in-place, but essentially act like Vulkan's transitions between the EXTERNAL queue
<daniels>
i.e. flush caches outbound, invalidate caches inbound
<daniels>
the client side wouldn't need to do anything, but in the compositor we could invalidate our existing images rather than destroy/create images every alskjdfasdfkj time
* ManMower
would love to see an end to the destroy/create cycle
<daniels>
srs
<daniels>
p sure it annoys emersion just as much as it does me as well :D
<emersion>
daniels: no need to craete/destroy textures
<daniels>
ah hmm, this is jogging the faintest of memories, but my brain is like a sieve :\
<emersion>
we've discussed about this with… lynxeye? i think
<daniels>
ah yes, EGL_KHR_image_base:
<daniels>
If an application specifies an EGLImage sibling as the destination for rendering and/or pixel download operations (e.g., as an OpenGL-ES framebuffer object, glTexSubImage2D, etc.), the modified image results will be observed by all EGLImage siblings in all client API contexts.
<daniels>
my god, well done EGL
<daniels>
though reading that spec has made me realise that we need to set EGL_IMAGE_PRESERVED_KHR = EGL_TRUE in the attribs ...
<daniels>
ManMower: ^ so yeah, looks like we can drop the destroy/create and let it live as long as the underlying wl_buffer, provided we just call glEGLImageTargetTexture2DOES with the image handle at the start of every repaint, and EGL_NO_IMAGE_KHR at the end of every repaint
<ManMower>
daniels: no need for EGL_EXT_image_flush_external extension at all then?
<emersion>
ah, what does EGL_IMAGE_PRESERVED_KHR do?
<daniels>
(as a further optimisation, you could cache the texture ID per-buffer and retarget during ->flush_damage(), rather than at every repaint, which would certainly help lame GPUs which need to make shadow copies)
<daniels>
ManMower: yeah!
<ManMower>
nice. :D
<daniels>
emersion: if it is EGL_FALSE, which is the default, then the contents of the image become undefined after you bind a sibling object in a client API (i.e. GLES texture)
<ManMower>
I'll play with that a bit later today if I get a chance.
<daniels>
ManMower: what better way to spend a Friday afternoon ... ?
<emersion>
that's… not great
<emersion>
does mesa handle it already?
<daniels>
emersion: yeah, it records the attrib you passed in and does absolutely nothing with it
<emersion>
cool
<daniels>
because this isn't 2006 and we don't do destructive transforms or assume that one producer frame == one consumer source
<wlb>
weston Issue #522 opened by Daniel Stone (daniels) weston_surface::committed is not as it seems https://gitlab.freedesktop.org/wayland/weston/-/issues/522 [Core compositor], [xdg_shell and wl_shell], [Good for new contributors]