02:08 wlb: weston Merge request !118 opened by Vivek Kasireddy (Vivek) WIP: Add support for XYUV format https://gitlab.freedesktop.org/wayland/weston/merge_requests/118
09:23 amosbird: hi, it seems ctrl-alt-Fnum is implemented inside xorg?
09:24 amosbird: I know this might not related to wayland but this channel is much more active and full of experts. I'd like post my question here :)
09:24 amosbird: so how can I take an area-screenshot when popup menus or IME is active?
09:28 baedert: sleep 3s && scrot, then do whatever you need and wait?
09:30 amosbird: baedert: is it possible to assign a hotkey even when popup menus are active?
09:30 amosbird: can I directly add hotkeys to xorg itself like ctrl-alt-Fnum keys?
09:31 baedert: amosbird: I thought that was one of the widely known downsides of X? That you can't do that?
09:31 amosbird: and wayland supports it?
09:38 aknautiy1: hi, how to use weston-debug, Currently I get a message that "wayland-server does not support weston-debug-v1-interface"
09:38 aknautiy1: Am I missing something?
10:00 daniels: amosbird: Ctrl-Alt-Fx is implemented inside your display server, yes - both Xorg and Wayland compositors
10:01 amosbird: daniels: hmm, so can I add a new hotkey to xorg?
10:01 daniels: amosbird: for Xorg, look at hw/xfree86/xkb/xkbVT.c
10:01 daniels: amosbird: er ... extremely painfully
10:01 amosbird: ...
10:01 daniels: aknautiy1: start weston with --debug
10:03 daniels: amosbird: the way VT switching is implemented involves a particular keysym being defined (step 1), the keysym being assigned to a key symbols definition in the xkb data (step 2), an xkb action being defined in the protocol (step 3), the keysym + modifiers being defined to produce that action in the compat definition (step 4), then the server recognising that action and doing the thing you want it to (step 5)
10:04 daniels: even if you implemented that in the X server, there's still the small matter of figuring out how you write your JPG/PNG/whatever file of the screenshot in the X server, assuming you've figured out how to implement the area selection by overriding the pointer grab in the first place
10:04 amosbird: ... sounds too complex to try
10:11 daniels: i wouldn't recommend it tbh
10:16 abique: Hi, let's say that I have a function similar to : void fct(uint32_t **data); how do I tell llvm ir that the N pointers in the data array don't alias with each other?
10:21 zubzub:checks channel name
10:21 zubzub: abique: I think you've got the wrong channel
10:23 abique: zubzub, obviously :-) Thanks!
11:55 romangg: pq: Since the EGLStreams debate is heating up again, I remember you saying some time ago you are not in favor of EGLStreams at all after taking a look at it. What are your arguments for that?
11:55 aknautiy1: daniels, thanks got it :).
11:57 pq: romangg, I think daniels can word the arguments much better, he has repeated them so many times. :-) I'm just totally agreeing to that.
11:58 daniels: heh
11:58 pq: romangg, simply put, the EGLStreams design takes away the knowledge of individual frames, which means that a compositor or a client cannot synchronize *any* window state with actual rendering.
11:58 daniels: romangg: https://lists.freedesktop.org/archives/wayland-devel/2016-March/thread.html#27547 and following on into April carry a lot of it
11:59 daniels: the tl;dr is that EGLStreams really is a very fully-encapsulated stream, and this breaks some parts of the protocol (subsurfaces in particular) which rely on frame-by-frame visibility
11:59 romangg: pq: Ok, can I read a summary somewhere. We are currently discussing the EGLStreams patches to KWin and I'm not so happy about some details, in particular that stuff is hidden. I fear we can't do future improvements to our DRM backend afterwards in regards to multi gpu, framerate sync and so on.
11:59 daniels: fully tying everything into EGL also seems like a bad idea when we have Vulkan on the horizon, not to mention everything else, like how do you handle interop with PipeWire ... ?
11:59 romangg: Also I would like at one point overlay scanout.
11:59 daniels: hah
12:00 daniels: the answer in that thread is that it would require several as-yet-unwritten extensions
12:00 daniels: a couple to implement dynamic consumer switching (between GL texture and KMS overlay), since right now the producer -> consumer relationship is fixed for the lifetime of the stream
12:01 daniels: a couple more to support atomic
12:02 romangg: Erik said the Nvidia driver supports atomic mode setting internally. How we in KWin can then interact with it I don't know yet.
12:02 pq: romangg, I'd say your fears of a technical dead-end are well founded, IMO.
12:03 daniels: well, you'd need new extensions to allow EGL to build up a configuration, then apply it all at once - not sure what those would even look like tbh. plus the interop thing was a big one for me: how does that work with multiple GPUs? or media codecs which give you dmabuf? or PipeWire or any other kind of external streaming?
12:04 ascent12: Is the plan to implement every single other API in EGL?
12:04 daniels: essentially all the infrastructure we've built for years has been based around surfacing as much knowledge and visibility into the pipeline as possible, whereas Streams fully encapsulates that into a closed abstraction, which either perfectly supports your usecase or does not support your usecase at all, nothing in between
12:05 ascent12: (that was supposed to be facetious, it may not have come across in text form)
12:05 daniels: heh
12:05 romangg: daniels: Yea, when looking at the code I felt the same. While libdrm gives me ample control, EGLStreams interfaces hide central parts of the pipeline.
12:06 romangg: Since GNOME has support for EGLStreams afaik how do they cope with these limitations?
12:07 daniels: gnome doesn't do overlays since it's too hard to pull them out from their scene graph atm
12:07 emersion: do they use atomic?
12:07 daniels: no
12:07 daniels: (not yet)
12:07 emersion: they do direct scan-out though, right?
12:07 daniels: i'm not sure how it works with pipewire - either there's some kind of vdpau interop, or perhaps more likely, they just ReadPixels and then that will be fast enough
12:08 daniels: emersion: i'm not sure if they do these days or not, but last I looked no. (pq?)
12:08 emersion: (cc jadahl)
12:08 emersion: hrm, ReadPixels :S
12:08 pq: when I was poking the insides of Mutter's native renderer, I very much ignored anything related to EGLStreams, so I can't say anythin about them
12:08 ascent12: I vaguely remember hearing they did do atomic in the past, but I might have been thinking about multi-gpu scanout
12:08 emersion: pipewire said they were looking into dma-buf support
12:09 daniels: nv doesn't do dmabuf ...
12:09 emersion: err
12:10 daniels: maybe since I last looked, but at the time they just used the OPAQUE_FD extension for Vulkan, and used a magic side channel to encapsulate tiling data, probably compression status, etc
12:39 RAOF: Hrm. Should the `wl_surface` in a `set_cursor` call already have a buffer attached?
12:40 RAOF: We warn in Mir when the `wl_surface` set as a cursor has no content (as the client should just be setting a null `wl_surface`, damnit), but GTK likes to set the cursor surface and then at some lazy point in the future actually fill that surface with content.
12:44 ascent12: It's odd, but nothing in the protocol seems to imply that it's forbidden. The normal wl_surface.attach(NULL) meaing unmapped would apply.
12:44 emersion: set_cursor(surface without a buffer) is the same as set_cursor(NULL)
12:44 emersion: set_cursor semantics have a lot of code paths, unfortunately
12:46 RAOF: Heh.
12:46 RAOF:adds "write some cursor-attaching tests to wlcs" to the TODO
12:47 pq: the no-NULL is a xgh-shell peculiarity most, IIRC
12:47 pq: *xdg-shell
12:48 RAOF: It just doesn't seem sensible to set a surface with no content as a pointer, when simply setting NULL as the pointer surface does the same thing.
12:48 ascent12: You'd think it'd make more sense for set_cursor to take a wl_buffer, but I suppose a surface would allow you to use wl_egl_window to render a cursor.
12:48 RAOF: I guess internally in GTK it's easier to attach the surface first and then render to it.
12:49 pq: ascent12, wl_surface also allows for viewport, scale and transform, and in the future colorspace information.
12:49 emersion: it also allows for subsurfaces :D
12:49 ascent12: pq: Right, I didn't think of that.
12:50 RAOF: <freenode_asc "You'd think it'd make more sense"> That doesn't work nicely for animated cursors; you lose `wl_surface`'s infrastructure for "please send me a new buffer now".
12:50 ascent12: ... I hope there isn't a client which is using subsurfaces on its cursors.
12:51 pq: RAOF, yeah, I'd think that set_cursor a contentless surface might cause the cursor to be unmapped before a buffer is committed to it, leading to a blink.
12:51 pq: but usually it doesn't blink, because the compositor rarely has a chance to repaint between set_cursor and commit
12:53 RAOF: I guess it would be churlish of us to raise a protocol error in this case :)
12:53 RAOF: Hm.
12:54 emersion: ascent12: tbh i'd just fallback to software cursors if that's the case, it wouldn't be hard at all
12:54 RAOF: Although it would be kinda nice to be able to send a warning to the client.
12:54 daniels: yeah, the original reason for set_cursor taking a surface rather than a buffer is so you could reuse wl_surface.frame for your animated cursors
12:54 ascent12: emersion: Yeah, a compositor can handle it, but it's still really really silly.
12:54 emersion: indeed
12:54 pq: emersion, why would you force software cursors instead of just compositing a stack of wl_surfaces in any way you can, without even knowing which one is a cursor? ;-)
12:55 daniels: ^ weston doesn't have any special plumbing from set_cursor -> hw cursor path; we just drop it into the stack of views we have
12:55 emersion: ahah, that's neat
12:56 daniels: ... obviously only for rendering, for moving the cursor around there's obviously some special-case handling :P
12:56 pq: daniels, there is?
12:57 RAOF: I'd like to switch Mir over to that; it just requires a little fiddling with the internals
13:00 pq: emersion, yeah, it's not hard to trick weston to put a weston-simple-shm window onto the cursor plane - hiding any actual cursor is often enough :-)
13:00 emersion: lol
13:00 emersion: really a shame we don't have zindex for planes
13:01 pq: whether that's useful is another matter, but usually there is a real cursor (or multiple!) as the top-most surfaces so those get picked first
13:01 daniels: pq: er yeah, weston_pointer_move_to() is connected to input events and uses those to move the position of the view created from set_cursor(cursor_surface) ...
13:01 daniels: emersion: KMS has a zpos property for hardware planes!
13:01 ascent12: A recall seeing some zpos patches recently, but I can't remember which driver it was
13:01 emersion: yeah, but does anybody support it?
13:01 pq: daniels, sure, but the backend doesn't know that. I just sees that a view changed position on the next repaint.
13:03 linkmauve: “14:01:02 pq> whether that's useful is another matter, […]”, I could think of a fullscreen game which gets disturbed by a notification, if it fits the cursor plane it won’t force compositing in the game.
13:05 pq: linkmauve, a good point. OTOH, I was thinking of the copying overhead into a cursor bo while the pixels were already copied into a GL texture.
13:05 linkmauve: ascent12, I’ve seen this property exposed on msm.
13:05 daniels: ascent12, emersion: yeah, iirc most drivers support it now; not all of them support actually _moving_ zpos (hardware constraints), but just give you an immutable declaration of what the fixed zpos actually is, which means you can place overlapping views into planes. weston has historically always punted on this precisely because zpos was undefined, apart from primary < overlays < cursor.
13:06 linkmauve: i915 still doesn’t seem to support it, as of 4.20.
13:06 linkmauve: Or maybe just on my hardware.
13:07 vsyrjala: i posted patches some years ago
13:07 ascent12: daniels: Awesome, even them being static is great. Things like the raspberry pi (forget the driver name) have so many planes, but you'd have to walk on eggshells if you want to use them correctly.
13:07 emersion: nice
13:07 linkmauve: daniels, btw, disabling Y-tiled modifiers in Weston fixed my issue for now, I still haven’t taken the time to look at the issue you pointed me to.
13:07 vsyrjala: the rule should be that w/o the zpos prop the obj id determines the order. but not sure all drivers follow that. i915 should
13:07 ascent12: Not having zpos was a pretty big reason why I was dragging my feet with overlay planes in wlroots
13:07 linkmauve: I now get tearing again in fullscreen Xwayland surfaces. \o/
13:07 linkmauve: Or /o\, not sure. :D
13:08 daniels: it's definitely present in sunxi, msm/fdno, omapdrm, exynos, rcar-du and sti - i've seen patches floating around for more I'm sure
13:08 daniels: oh, and tegra
13:09 daniels: linkmauve: woohoo
13:09 daniels: vsyrjala: yeah, that was definitely not strictly observed
13:09 daniels: ascent12: rpi == vc4, and yeah, that was one of the ones I was expecting to have it ...
13:25 vsyrjala: if someone wants to play with zpos on i915 let me know and i can rebase my stuff. but note that you can only get configurable zpos on vlv/chv, other platforms have it fixed
13:28 ascent12: Will the property have the immutable flag set if it's static and unset otherwise?
13:32 vsyrjala: that is how i was going to do it. https://patchwork.freedesktop.org/series/43902/
13:32 vsyrjala: not sure there is any rule/agreement on the use of the immutable flag though
13:33 ascent12: It seems like the most sensible thing to me, but I'm no kernel developer
13:34 vsyrjala: hmm. i guess a bunch of us did agree on account of drm_plane_create_zpos_immutable_property() existing
13:41 daniels: yeah, that's where everyone landed
14:12 unidan: Hi, to update the position of a subsurface, do you always need to attach + commit the parent surface ?
14:13 emersion: you can commit without attaching
14:13 emersion: (it'll keep the previous buffer)
14:19 unidan: oh, I've been tricked by the "After commit, there is no pending buffer until the next attach" and though the opposite
14:20 unidan: but you still need the commit on the parent surface
14:23 emersion: yes
14:23 emersion: maybe you don't need to if the subsurface is async?
14:23 daniels: emersion: correct
14:23 daniels: in async mode, the child updates completely independently from the parent
14:24 daniels: you only need sync mode when you really need both to update at the same time - for instance when you're resizing
14:31 unidan: The documentation says: This state is applied when the parent surface's wl_surface state is applied, regardless of the sub-surface's mode
14:32 unidan: this seems a bit strange for subsurface and I was mostly wondering if I understand the behaviour correctly, but I'll do more extensive tests
14:34 pq: sub-surface's position is state on the parent surface, not the sub-surface itself
14:35 pq: that is because quite likely the parent surface content requires the sub-surface to be in a certain place to look consistent, e.g. if the parent surface has something drawn around the sub-surface
14:36 pq: therefore in most cases moving the sub-surface without also updating the parent surface content to match would not make sense
14:46 unidan: I understand
14:48 unidan: I'm in an edge case where I try to draw video behind a transparent interface, but as the video aspect ratio change I must adapt its position and size, so I have a scaled black surface behind and was wondering if I could remove it from the video output module
14:49 unidan: (so that I can remove it if needed)
14:52 pq: unidan, sorry, I'm not sure what you're asking. What is the purpose of the black surface?
14:54 unidan: the interface is above and transparent, but the video can be smaller than the window. The black surface avoid having the borders being transparent
14:54 pq: unidan, ok. Can the video be smaller intentionally, or is it just during a transition when the size changes?
14:55 unidan: intentionnally
14:55 unidan: for example when playing a 4:3 video on a 16:9 window
14:55 pq: right. What is the issue if you still have one?
14:57 unidan: mostly that I wanted to avoid having the video output module commit the parent surface, but it is mostly answered here
14:57 unidan: though I wonder if scaling a black pixel is the correct solution for the background window
14:58 pq: Cool. Yeah, scaling a single black pixel is the most efficient way, but you may need to have a fallback path in case the wp_viewporter extension is not available.
14:58 pq: assuming that is what you use
14:58 unidan: yes
14:59 unidan: I tried to use /dev/null instead of shared memory but ran into protocol error, is it unsupported?
15:01 pq: one cannot read anything from /dev/null, maybe /dev/zero might have a chance to work?
15:02 unidan: oh, I'll try to be less stupid
15:02 unidan: thank you for the tips
15:02 pq: that's an interesting idea for a trick :-)
15:02 emersion: indeed
15:04 unidan: actually not mine :)
15:04 unidan: and looking back at it, I was told /dev/zero and must have assumed both were the same, so TIL
15:16 amosbird: um
15:16 amosbird: anyone knows xosd?
15:16 amosbird: is it possible to make the font bigger?
21:11 daniels: emersion: thankyou!
23:51 emersion: eh, np