04:43wlb: wayland Issue #400 opened by zayn lie (zayn7lie) Failed to Detect Real Position of Cursor https://gitlab.freedesktop.org/wayland/wayland/-/issues/400
04:45wlb: wayland Issue #400 closed \o/ (Failed to Detect Real Position of Cursor of Mouse https://gitlab.freedesktop.org/wayland/wayland/-/issues/400)
06:17zzxyb[m]: Is it better to add isprimaryoutput to the zxdg_output_manager protocol?client needs to know the change information of the primary screen of the wayland server
06:51kennylevinsen: zzxyb[m]: there is no concept of primary output in Wayland
06:58zzxyb[m]: <kennylevinsen> "zzxyb: there is no concept of..." <- but libraries like qt have the concept of primary screen,shouldn't the primary concept be expanded?
06:59zzxyb[m]: xcb also has xcb_randr_get_output_primary, should we consider it?
07:01zzxyb[m]: or should this be handed over to kwin or wlroots to make custom protocols?
07:02kchibisov: I think it was discussed though the years on wayland-protocols, so you can read on it there.
07:03zzxyb[m]: ok thanks！
07:03kchibisov: The primary output concept is just exposing bad behavior, because some games try really hard to stick to so called primary output.
07:04kchibisov: Most requests have an option to pass `nil` instead of wl_output, so it'll try to pick some output (preferred by compositor) automatically.
07:10wlb: wayland-protocols Issue #154 opened by xyba (xyba) zxdg_output_manager protocol Lack of isprimaryoutput tag https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/154
07:17zzxyb[m]: but for multi-screen mode, how the application should be displayed on the primary screen is useful.like ike kde there is kde-primary-output-v1.xml.there may be some features when there are multiple screens, such as the taskbar on the primary screen
07:19zzxyb[m]: there will always be normal apps that want to show up on the primary screen
07:20kennylevinsen: apps do not have any control over where they are shown. the compositor can internally prioritize displays however it likes.
07:22kennylevinsen: (although making stuff appear on the "primary" output is - in my opinion - really bad UX on the platforms that do it. If I'm focused on screen X, triggered menus and apps shouldn't open on screen Y >.>)
07:22kchibisov: kennylevinsen: they could refuse to leave the output as well.
07:23kchibisov: I remember some games move back when you try to move them away from primary output.
07:23kennylevinsen: hah, that sounds horrible
07:23kennylevinsen: why fight the user?
07:23kchibisov: I mean that's how game development works.
07:23zzxyb[m]: kennylevinsen: yes,to expand, the primary screen is designed in some systems to be able to set any screen
07:24kchibisov: They likely set all the state on each frame including output.
07:25kennylevinsen: kchibisov: ah so they do it by accident? but that's certainly a good counterexample to having primary outputs
07:25kchibisov: I'm not sure, I just seen games who refuse to launch on anything other than primary output.
07:25kchibisov: That's the same with some games I ran in xwayland, they used dimensions of so called primary output.
07:26kchibisov: while they were somewhere else.
07:27kennylevinsen: zzxyb[m]: the concept when exposed to clients has been NACK'd over and over as being detrimental and without merit, but as kchibisov suggests, reading the discussions on the mailing list and gitlab would be better - it might offer a more nuanced response.
07:28zzxyb[m]: ok
07:48ofourdan: For Xwayland (wrt the point about games running on Xwayland and not using the primary monitor), the Wayland compositor / X11 window manager can set the primary monitor using XRandR in Xwayland, that's what mutter does. Obviously, that does not help with Wayland native apps.
08:34wlb: weston Issue #781 opened by Marius Vlad (mvlad) desktop-shell: Set parent to nil on surface without a parent https://gitlab.freedesktop.org/wayland/weston/-/issues/781 [Desktop shell]
08:37wlb: weston/main: Derek Foreman * libweston: Remove plane clip https://gitlab.freedesktop.org/wayland/weston/commit/550c4c3dbc49 include/libweston/libweston.h libweston/compositor.c
08:37wlb: weston/main: Derek Foreman * paint_node: Fix paint_node_damage_below https://gitlab.freedesktop.org/wayland/weston/commit/43b59786e644 libweston/compositor.c
08:37wlb: weston Merge request !1326 merged \o/ (Fix damage when switching back to primary plane https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1326)
08:47wlb: weston Issue #782 opened by Marius Vlad (mvlad) desktop-shell: Panel and background resizing https://gitlab.freedesktop.org/wayland/weston/-/issues/782 [Desktop shell]
09:09zamundaaa[m]: zzxyb: fyi the kde protocol was for plasmashell only, and is no longer used as it turned out to not be good even for the shell
09:09wlb: wayland Issue #400 closed \o/ (Fail to Detect Real Position of Cursor of Mouse https://gitlab.freedesktop.org/wayland/wayland/-/issues/400)
09:09wlb: wayland-protocols Issue #154 closed \o/ (zxdg_output_manager protocol Lack of isprimaryoutput tag https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/154)
11:56drakulix[m]: I totally missed doing a doodle for this weeks governance meeting...
11:57drakulix[m]: Normally the selected date was announced on Monday, sooo.. should we re-schedule for next week instead?
12:33d_ed[m]: Ok. I'm still going through my backlog of assigned tasks anyway
13:50zzxyb[m]: <zamundaaa[m]> "zzxyb: fyi the kde protocol..." <- seems to find the same kind of issues:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/153
15:46wlb: wayland-protocols Merge request !239 opened by Julian Orth (mahkoh) xdg-shell: configure serial is not 0 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/239
16:50wlb: wayland-protocols Merge request !239 closed (xdg-shell: configure serial is not 0)
17:11orowith2os: How bad would it be if I learned Wayland and X by implementing (basically the polar opposite of) Xwayland?
17:12orowith2os: My sanity is already at its limits, sooooo
17:13orowith2os: I know you can just nest Weston, but bring more tightly integrated would be a goal
17:13orowith2os: *being
17:14vyivel: so like, get an xdg_toplevel and create a corresponding x11 window?
17:14orowith2os: More or less
17:14vyivel: sounds fun
17:15orowith2os: The painful parts are, of course, going to be learning the convolutedness of X, and fighting the compiler (as I can't write very good C)
17:15vyivel: considering that wayland is about policy rather than mechanism the translation should(?) be somewhat straightforward
17:16orowith2os: It would be nice to have as much as possible only support Wayland, and have backwards compat by way of a compat layer
17:17orowith2os: Less reason for things to support X backend
17:19orowith2os: So I guess a better question would be, how much pain should I expect, and are there some decent (ideally modern) resources for learning both sides of the equation?
17:20orowith2os: Hoping the Rust bindings hold up here, or some cursed mix of C <-> Rust is resorted to
17:26kchibisov: I'm still looking for resources to learn about X11 in a sane way.
17:27orowith2os: Perfect! I'll be sure to get my therapist ready
17:27kchibisov: The main issue is that stuff is simply not documented.
17:27kchibisov: Like you have some documentation.
17:28kchibisov: But some stuff could only be figured out from other folks doing X11 for years.
17:47DodoGTA: Does Xorg have reference counts?
17:48bittin_GUADEC: heya
17:50orowith2os: @DodoGTA a quick Google search shows some hits
17:50orowith2os: So at least in some places
17:52orowith2os: A gitlab search shows some references to it in docs
17:52DodoGTA: orowith2os: I wonder if it's worse than COM though
18:08kchibisov: DodoGTA: the thing is that some spec impl tied to specific lib.
18:08kchibisov: So you have to read the code pretty much most of the time to understand why something works like that.
18:09kchibisov: E.g. when trying to use xinput2 you'll break xim, because it's all done in xlib and xlib only does xinput.
18:09kchibisov: Even though, nothing really stops from using xinput2 with xim, because you can build XKeyEvent from the xinput2 event for keyboard just fine.
18:10kchibisov: So you'd have to go with xcb, for example, but then you realize that you don't have xim anymore and you have to wire it up yourself.
18:10kchibisov: it's just all over the place.
18:11kchibisov: With wayland you just read spec write what is written and 99% of the time you're good.
18:12kchibisov: And x11trace compared to WAYLAND_DEBUG is just not helping at all.
18:13kchibisov: You could also find during development that XWayland behaves way more sanely than real X.org.
18:13kchibisov: e.g. XPresent only works the way you could expect from it to work only under XWayland, with real X it's just doing something completely arbitrary.
18:15kchibisov: I remember being told here that I could use XPresent to implement something similar to frame callbacks, and it really workde the same on XWayland but on real X it was just not delivering any of the events any more.
18:22emersion: wlroots does that
18:22emersion: it works on regular X as well
18:43kchibisov: emersion: I mean it works, but not like on wlroots.
18:43kchibisov: You simply can't rely whether your window was presented or not anymore.
18:43kchibisov: You can only use timing.
18:45kchibisov: So your frame rate goes from display refresh rate(on wlroots) to 20 (that was in my case with i3 and default X).
18:50kchibisov: Though, I've lost a logs when debugging it, but basically only `ust/msc/sbc` where stable, the `CompleteNotify` event worked completely different.
18:51kchibisov: That's just an example that worked on XWayland, but then failed on X11 https://github.com/rust-windowing/winit/pull/2535